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interaction 



(57) A system for simulation of target electronic sys- 
tems combining interacting elements of hardware and 
executing software, in part by physical emulation means 
and in part by abstract software simulation. A processor 
emulator (202) is coupled to a hardware simulator (206) 
by a communications link (220,222). The processor 
emulator provides the functionality of the target micro- 
processor while the hardware simulator simulates addi- 
tional target circuitry The processor emulator is coupled 
to a memory (226) containing the target program (22). 
Most computer instructions in the target program do not 
require interaction with the target circuitry simulated on 
the hardware simulator. However, when a computer 



instruction requires the interaction of the target micro 
processor and the target circuitry a communications 
interface controls the communication between the tar- 
get microprocessor and the target circuitry. The various 
components of the system can be coupled together via 
a conventional computer network. A translator/mapper 
(21 0) translates the computer data requiring the interac- 
tion between the target microprocessor and the target 
circuitry from the data format of the emulator to the data 
format of the hardware simulator. The translated data is 
then mapped to a set of simulated pins on a processor 
model shell (210) in the hardware simulator 
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Description 

Technical Field 

The present invention relates generally to computer 
hardware simulators, and, more specif icailyp to a system 
and method for the simulation of systems that combine 
hardware and software interaction. 

Background of the Invention 

The use of computer simulation has become wide- 
spread in many areas such as circuit design. The cost of 
manufacturing an integrated circuit is extremely high, 
and it is desirable that the hardware incorporated Into 
the integrated circuit be tested prior to the actual fabri- 
cation of the chip. To that end, integrated circuit manu- 
facturers often use simulators to test the hardware and 
the software intended to be executed by the hardware. 
The desired hardware design is designated as the tar- 
get hardware, while the software intended to be exe- 
cuted by the target hardware is designated as the target 
program. 

There are several techniques that are used to sim- 
ulate the target hardware and software. One approach 
is to simulate the hardware using a computer hardware 
simulator. The hardware simulator is a software pro- 
gram that simulates the responses of the target hard- 
ware and is implemented entirely in software. Thus, in 
the hardware simulator, the target hardware and target 
program are simulated entirely by computer software. 
Another approach uses a microprocessor emulator to 
model a microprocessor that is typically part of the tar- 
get hardware and used to execute the target program. 
Thus, the target program and portions of the target 
hardware are simulated by hardware devices such as 
the processor emulator. 

Each of the above-described approaches has 
advantages and disadvantages. The hardware simula- 
tor is extremely slow and cumbersome, particularly 
when used to simulate a complex microprocessor exe- 
cuting a target program. Thus, testing a complete target 
program is impractical due to the extremely long execu- 
tion times required by the typical hardware simulator. 
The processor emulator is able to execute a target pro- 
gram much faster than the hardware simulator but 
requires the development of external circuitry that is 
expected to interact with the target microprocessor. 
Therefore, it can be appreciated that there is a signifi- 
cant need for a system that allows complete testing of 
the target hardware and software with efficiency and 
low cost. The present invention provides this and other 
advantages, as will be illustrated by the following 
description and accompanying figures. 

Summary of the Invention 

The present invention is embodied in a system and 
method for testing and analyzing electronic systems, 



including a target microprocessor and simulated target 
circuitry, and accompanying target software to be exe- 
cuted on the target microprocessor. The system com- 
prises a memory storing a plurality of computer 

5 instructions, including the target software and a proces- 
sor emulator employing a hardware device for emulating 
the microprocessor. The processor emulator is coupled 
to the memory to execute the computer instructions, A 
hardware simulator is coupled to the processor emula- 

10 tor to simulate the target circuitry. A communications 
interface controls communication between the memory, 
the processor emulator, and the hardware simulator. 
The processor emulator communicates with the mem- 
ory to receive the conputer instructions and communi- 

75 cates with the hardware simulator using the 
communications interface only on an occasion when the 
target software requires interaction with the target cir- 
cuitry. 

The processor emulator may be coupled to the 

20 hardware simulator by computer network connection, 
with the communications interface controlling communi- 
cations over the network. The system may also include 
an exception detector coupled to the processor emula- 
tor to detect the occasion requiring the target software 

25 to interact with the target circuitry The exception detec- 
tor may tennporarily halt execution of the plurality of 
computer instructions while the hardware simulator 
processes the occasion requiring the target software to 
interact with the target circuitry The occasion requiring 

30 the target software to interact with the target circuitry 
may be an input/output (I/O) instruction to the hardware 
simulator, with the communication interface controlling 
communication of the I/O instruction from the processor 
emulator to the hardware simulator. 

35 The processor emulator typically utilizes a first data 
format, and the hardware simulator uses a second data 
format. The system includes a translator to convert an 
event requiring the target software to interact with the 
target circuitry from the first data format to the second 

40 data format for events requiring interaction. The hard- 
ware simulator may contain a processor model shell to 
simulate the target circuitry. In such circumstances, the 
system also includes a mapper to map the event type to 
a set of signal sequences compatible with the processor 

45 model shell. The processor emulator may be coupled to 
the translator and mapper by a first computer network 
connection, with the communications interface control- 
ling communication over the first network connection. 
The translator and the mapper may be coupled to the 

50 hardware simulator by a second computer network con- 
nection, with the communications interface controlling 
communication between the processor emulator and 
the hardware simulator over the first and second net- 
work connections. In a preferred embodiment, the map- 

55 per may directly determine the event type and map the 
event type into a set of signals compatible with the hard- 
ware simulator without the need of a translator. 

In one embodiment the processor emulator is a 
microprocessor emulator with the memory integrated 
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therein with the integrated memory containing the com- 
puter instructions. In an alternative embodiment the 
processor emulator is a hardware circuit emulator with 
memory integrated therein, with the integrated memory 
containing the connputer instructions. 5 

In another alternative embodiment, the system 
includes first and second target microprocessors each 
having a memory storing a set of computer instructions 
to be executed on the respective target microproces- 
sors. In this embodiment, the communications interface 10 
controls communication from the first and second proc- 
essor emulators to the hardware simulator. The first and 
second processor emulators communicate with the first 
and second memories, respectively, to receive the first 
and second sets of conrputer instructions therefrom, is 
The first processor emulator communicates with the 
hardware simulator using the communications interface 
only on an occasion when the target software for the 
first target microprocessor requires interaction with the 
target circuitry and the second processor emulator com- 20 
municates with the hardware simulator using the com- 
munications interface only on an occasion when the 
target software for the second target microprocessor 
requires interaction with the target circuiti-y 

The dual target processor embodimerrt may also 25 
include first and second portions for tiie communica- 
tions controller, with the first communications controller 
portion being operatively coupled to the first processor 
emulator to control communication between the first 
processor emulator and the hardware simulator only on 30 
the occasions when the target software for the first tar- 
get microprocessor requires interaction with the target 
circuitry. The second communications controller portion 
is operatively coupled to the second processor emulator 
to control communications between the second proces- 35 
sor emulator and the hardware simulator only on occa- 
sions when tiie target software for the second target 
microprocessor requires interaction with the target cir- 
cuitry. In this embodiment, the first and second proces- 
sor emulators may be microprocessor emulators or 40 
hardware circuit emulators. 

Brief Description of the Drawings 

Figure 1 is a functional block diagram of a tradi- 45 
tional hardware simulator employing a processor func- 
tional model to simulate target program execution. 

Figure 2 is a functional block diagram of a conven- 
tional instruction set simulator. 

Figure 3 is a functional block diagram of a tradi- so 
tional hardware simulator employing a hardware mod- 
eler to simulate target program execution. 

Figure 4 is a functional block diagram of a conven- 
tional processor emulator. 

Figure 5 is a functional block diagram of a conven- ss 
tional hardware circuit emulator. 

Figure 6 is a functional block diagram of the present 
invention. 

Figure 7 is a table of processor operations which 



are used as part of a communications protocol with the 
system of Figure 6. 

Figures 8A and 8B are flowcharts illustrating the 
operation of the control program in the present inven- 
tion. 

Rgure 9 is a functional block diagram of a dual 
processor configuration of the present invention 
employing two processor emulators. 

Rgure 10 Is a block diagram of a dual processor 
configuration of the present invention employing a proc- 
essor emulator and a software processor simulation 
engine. 

Detailed Description of the Invention 

With the advent of 32-bit microprocessors and com- 
plex operating software, embedded systems have 
become very conrplex systems. The vast majority of 
electronic products built today include some form of 
computer hardware executing a stored software pro- 
gram. An embedded system may typically include a 
microprocessor executing instructions and interacting 
with an application specific integrated circuit (ASIC) or a 
custom Integrated Circuit (IC). The microprocessor 
used in the system is designated herein as a target 
microprocessor The external circuitry that interacts with 
the target microprocessor, whether it is the ASIC, cus- 
tom IC, or some other form of electronic circuitry, is des- 
ignated herein as the target circuitry. The combination 
of the target circuitry and tiie target microprocessor is 
designated herein as the target hardware. The software 
program that is intended to be executed by the target 
microprocessor is designated herein as the target pro- 
gram. 

Given the complexity and density of modern elec- 
tronics designs, it is desirable that the first system pro- 
totype, including tiie target hardware and tiie target 
program, is typically close in form, fit, and function to the 
end product. The target hardware prototypes would 
therefore include the ASIC and custom IC designs, 
which were fabricated and passed their respective qual- 
ification and acceptance tests at the foundry 

With respect to the target program, code is typically 
designed, written, and tested, module by module. The 
module integration process also involves testing of the 
integrated software modules. However, because the tar- 
get hardware may not be available at the time of the 
software development, it is not possible to test the inter- 
action of the target hardware and the target program. To 
substitute for the missing target hardware, pieces of the 
design are "stubbed out," or mockups built to substitute 
for anticipated missing parts of tiie target hardware. The 
term "stulDbed out" refers to a mock response to a pro- 
gram call to a location in the yet unbuilt circuitry. The 
programmer must program a return command that 
causes the target program to ignore the lack of a true 
response from the target circuitry The substitution of 
mocked up target hardware requires further interpreta- 
tion of the original hardware design specifications. It is 
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common to find that no single combined softv^re sys- 
tem integration occurs before the software is loaded 
onto the hardware prototype, let alone tested as a whole 
(stubbed out or othenA^ise). 

When software engineers start work, the physical s 
target hardware which will ultimately execute the target 
program does not exist. The target program can be 
cross-compiled onto an existing system for testing, and 
the hardware-dependent parts of the target program 
can be emulated with other software modules. Typically, 10 
this entails writing simulated hardware functions to sim- 
ulate the low-level interaction with the target hardware, 
allowing a "black-box" approach to the design. Thus, a 
particular software function can be written to simulate a 
response expected from the target hardware. If the pro- is 
jected target hardware changes, then only the particular 
simulated hardware function need be modified. The rest 
of the simulation program remains unchanged. This 
approach also allows some conceptual testing to occur. 
However, the ability to emulate the target hardware in 20 
custom software modules is normally very limited. It can 
be a lengthy modeling task to write an equivalent func- 
tional module of the unbuilt target hardware. It can be an 
even larger task to verify that the software module pro- 
vides compatible responses to the target hardware dr- 25 
cuit because the software module is simply the 
programmer's interpretation of the original system spec- 
ifications. The target program is not normally used with 
this approach, unless the development system happens 
to be the expected target computer system to some 30 
large extent. 

Typically, the hardware and software components 
of a target system design are brought together for the 
first time when the prototype target hardware has been 
fabricated. Because of the prior unavailability of the 35 
actual target hardware, one often finds that the target 
program loaded at the time of the integration of the pro- 
totype target hardware and software does not work. It is 
common to find that the integration problems are strictly 
due to software complications alone. This may cause a 40 
significant delay in the software development due to the 
problems In the target program. Other problems with the 
integration may be caused by the interaction of the tar- 
get hardware with the target program. Consequently, 
considering the large cost of ASIC and custom IC 45 
design, and the relatively low cost ease of software 
modification, it is common that the software will be 
force-fitted to the target hardware prototype, thereby 
increasing the overall planned software development 
time. so 

The target hardware can be simulated at the chip, 
board, and system level to varying extents. Because of 
the availability of simulated target hardware, there is a 
signrficant benefit to including the target program in a 
system simulation, including the chance to debug code ss 
and verify the correct operation of both the target pro- 
gram and target hardware before the target hardware is 
built. Problems associated with the interaction between 
the target hardware and the target program can be 



detected and corrected before final hardware fabrica- 
tion, often saving costly and time-consuming redesign 
of the ASIC. 

Current technology facilitates only primitive and low 
performance hardware and software simulation. Large 
amounts of processing power are required to simulate a 
microprocessor executing a few hundred lines of the tar- 
get program code. Traditional hardware simulated 
microprocessors execute approximately 1 -4 microproc- 
essor instructions per second, which barely allows for a 
system to boot itself up. Meaningful system simulations, 
where significant amounts of target program code are to 
be executed, require massive computing resources. 

The target hardware prototype is built in order to 
verify that the target program runs with the custom 
designed target circuitry and target microprocessor. 
One issue in using the target hardware prototype is the 
loss of debug visibility once the prototype is built. As 
those skilled in the art can readily appreciate, the typical 
embedded system does not have any debugging and 
control capabilities. When errors are detected in the 
prototype target system, there are no facilities to utilize 
the software development tools required to debug, ana- 
lyze and correct the problems. A loss of visibility refers 
to the inability to examine the contents of internal regis- 
ters, memory locations, and the like. The prototype 
hardware also lacks debugging control ability, which is 
the ability to control the flow of the target program using 
start and stop command, single step commands, and 
the like. 

A brief discussion of conventional simulation sys- 
tems will serve to distinguish the present invention. 
Conventional simulations systems can be categorized 
as hardware, software, or a combination. The "brute- 
force" hardware simulation method of verifying the tar- 
get system, illustrated in Figure 1 , uses a hardware sim- 
ulator 20. The hardware simulator 20 is a software 
program that accepts a description of the target hard- 
ware, including electrical and logical properties of the 
target microprocessor and the target circuitry. The tar- 
get hardware design may be specified graphically by 
schematic diagrams or by a hardware description lan- 
guage (HDL), such as VHDL The hardware simulator 
20 is a commercially available product. 

The hardware simulator 20 simulates signal propa- 
gation and logical functionality of the target hardware 
event by event. It should be noted that a typical micro- 
processor instruction cycle is actually the result of a 
large number of hardware events within the target. 
Thus, the hardware simulator 20 attempts to represent 
signal timing, signal strength, and logical function as 
accurately as possible, often enabling sub-nanosecond 
timing accuracy in simulating these hardware events. To 
achieve this degree of accuracy for a highly complex tar- 
get microprocessor, functions are often represented 
with detailed structures, although most hardware simu- 
lators allow multiple levels of modeling abstraction from 
a switch or transistor level model to a high level behav- 
ioral model. 
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A target program 22. is compiled into object code, 
and the object code is downloaded into a processor 
memory model 24 within the hardware simulator 20. A 
processor functional model 26 is a software description, 
including the electrical and logical properties, of the tar- 5 
get microprocessor, while a target circuitry functional 
model 28 provides a model of the target circuitry, such 
as an ASIC, or other custom or semi-custom design. 
The hardware simulator 20 allows the processor func- 
tional model 26 to simulate execution of the target pro- 10 
gram 22 event by event. As discussed above, the 
processor functional model 26 and the target circuitry 
functional model 28 can be specified to various levels of 
abstraction by a conventional HDL. 

There are disadvantages in using the hardware is 
simulator 20 to simulate the target hardware. Microproc- 
essor manufacturers are cautious about providing the 
full-functional processor model 26 that could be 
reverse-engineered into a competitive product. In addi- 
tion, the full-functional processor model 26 can be 20 
extremely detailed for a complex circuit such as the tar- 
get microprocessor. For an accurate simulation, the 
hardware simulator 21 must simulate all activity that 
occurs in the target microprocessor using the processor 
functional model 26 to detect timing errors, race condi- 2S 
tions, and the like. This requires many processor cycles 
in the hardware simulator 20 to simulate each instruc- 
tion of the target program 22 by the target hardware. 
The execution time required to simulate the full-func- 
tional processor model 26 can add significantly to the 30 
simulation run-times. The target program 22 can be 
quite long. The additional burden of trying to run longer 
simulation required for larger target program 22 into the 
processor memory model 24 can consume large 
amounts of system resources, and simulation run time 35 
can become unacceptably long. Typical simulation 
speeds may only reach 2-4 microprocessor instructions 
per second. 

If the target program 22 malfunctions, then the pro- 
grammer has the unenviable task of debugging the tar- 40 
get program and relating the object code locations back 
to some high-level program statements outside the typ- 
ical software development environment. This debugging 
task must typically be accomplished without the aid of 
debuggers or any other software design and analysis 45 
tools. 

Variations on the use of the full functional model 26 
in the hardware simulator 20 include a trade-off in both 
timing accuracy and gross functionality. To speed the 
overall hardware simulation, timing accuracy Is some- so 
times only maintained for major processor or bus 
cycles, reducing the overall number of simulated events. 
However, the loss of such detailed analysis means that 
timing problems and race conditions may not be reliably 
detected. Delay calculations can also be curtailed using ss 
"zero-delay" timing for hardware functions. A zero-delay 
timing system assumes that all events happen without 
propagation delays or response delays. This assumes 
that all internal functions In the target microprocessor 



occur with zero delay and that response from that target 
circuitry also occur with zero delay While this approach 
speeds up the simulation, it does not provides an accu- 
rate simulation of the system timing. 

Another form of software simulation of the target 
hardware uses an instruction set simulator (ISS) 40. 
illustrated in Figure 2. The ISS 40 Includes a memory 42 
that contains the target program 22. The ISS 40 strives 
to guarantee functional accuracy of both instruction 
functions and memory references only at the processor 
instruction level. As a result, accuracy to detailed inter- 
nal timing is sacrificed for speed. The speed of a typical 
ISS 40 is on the order of 1.000-10,000 microprocessor 
instructions per second. While the ISS 40 provide a 
functional model of the target microprocessor, they do 
not interface with custom designed hardware such as 
the ASIC. The ISS 40 executes the target program 44, 
but has only limited visibility to circuitry outside of the 
target microprocessor. The typical ISS 40 does not rep- 
resent any custom target circuitry in simulation beyond 
a register reference, and hence is of limited value to 
hardware designers. 

The systems illustrated in Figures 1 and 2 simulate 
the target hardware completely in software. As is known 
by those of ordinary skill in the art, software simulation 
of the target hardware offers relatively low cost and flex- 
ibility in altering the simulated target hardware. How- 
ever, the total software simulation approach suffers from 
the disadvantages that the target hardware often cannot 
be completely modeled. In addition, the simulator 
processing time is enormous for the processor func- 
tional model 26 (see Figure 1) making it difficult or 
impossible to simulate the complete target program 22. 

A common technique to address the unacceptably 
long run-times encountered with the full functional 
model 22 (see Figure 1) is to replace the full functional 
model in the hardware simulator 20 with a physical inte- 
grated circuit (IC) microprocessor 50, as illustrated in 
Figure 3. The microprocessor 50 is connected to the 
hardware simulator 20 via a hardware modeler 52. The 
target program 22 is contained in the memory model 24 
in the hardware simulator 20. and all instructions are 
executed out of the memory model 24, as previously 
discussed with respect to Figure 1 . A significant differ- 
ence between the system illustrated in Figure 1 and that 
of Figure 3 is that the processor functional model 26 
(see Figure 1), which is simulated completely in soft- 
ware, is replaced by the physical microprocessor 50 and 
the hardware modeler 52. The microprocessor 50 may 
be the actual target microprocessor or other circuit to 
simulate the behavior of the target microprocessor. It 
should be noted that the physical microprocessor 50 
and the hardware modeler 52 are hardware compo- 
nents rather than software simulations. The cost of the 
typical hardware modeler 52 can be quite high, ranging 
from $40,000 to over $200,000. 

While the use of the hardware modeler 52 can pro- 
vide a full functional processor model, regardless of 
processor complexity, the significant extra cost of the 
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hardware mcxieler 52 is not always reflected by an 
increase in simulation performance. The hardware mod- 
eler 52 contains a vector memory (not shown) to store 
the input data for each pin of the physical microproces- 
sor 50 for each time slice of the hardware sinruilator. A 5 
time slice can be arbitrarily small, and is typically less 
than a single microprocessor dock cycle. As previously 
discussed, the detection of timing problems requires an 
event by event analysis, including propagation delays, 
of the target hardware. The hardware modeler 52 runs 10 
lockstep with the hardware simulator 20 with the physi- 
cal microprocessor 50 generating the next set of binary 
signals from the vector memory at the microprocessor 
pin connections for incorporation with the next simu- 
lated step of the hardware simulator 20. Thus, the hard- rs 
ware modeler 52 operates in complete synchronization 
with the hardware simulator 20. 

The processor in the hardware modeler 52 is often 
a dynamic device that must maintain a running clock in 
order to retain data. Because the hardware simulator 20 20 
simulates the system responses event by event for an 
arbitrarily small time slice, the physical microprocessor 
50 must wait for each simulation cycle to be completed 
by the hardware simulator 20. Therefore, the physical 
microprocessor 50 must be reset and the start of each 25 
simulation cycle, and all the previous vectors rerun. As 
the simulations get longer, the time taken to rerun all the 
previous vectors increases. Executing the target pro- 
gram 22 takes a large number of clock cycles, often 
exceeding the maximum amount of vector memory 30 
available for the hardware modeler 52, and thus 
severely limiting the length of the target program. In 
addition to the large memory requirement in the hard- 
ware modeler 52. the execution of the target program 24 
at the object-code level does not provide a convenient 35 
means for debugging the target program 22. 

The system illustrated in Figure 3 uses some hard- 
ware, namely the hardware modeler 52» to model por- 
tions of the target hardware. However, as discussed 
above, this approach is both costly and limited in its abil- 40 
ity to model the large size of the typical target program 
22. Another device used to model the target processor 
is a processor emulator 60, illustrated in Figure 4. The 
processor emulator 60 is a hardware device that substi- 
tutes for the target microprocessor. Processor emula- 45 
tors are conventional devices presently available from 
sources such as Applied Microsystems Corporation. 
The system illustrated in Figure 4 includes a portion 62 
of the target hardware, including a memory 66 contain- 
ing the target program 22, and a socket 70 for the target so 
microprocessor. The processor emulator 60 is coupled 
to the portion 62 of the target hardware by a data bus 72 
and typically plugs directly into the socket 70 as a sub- 
stitute for the target microprocessor. 

The processor emulator 60 includes a microproces- 55 
sor 76, which is typically the target processor. The proc- 
essor emulator 60 may also include an emulator 
memory 78 and a control circuit 80. The processor emu- 
lator is coupled to a workstation 84 or computer terminal 



by a communications link 86. The workstation 84 may 
be a stand-alone computer workstation or simply a ter- 
minal coupled to a conputer (not shown) to which the 
processor emulator 60 is also coupled. User interface 
software 88 within the workstation 84 controls the dis- 
play of data on the workstation and permits user input to 
the emulator. The user interface software 88 and the 
control circuit 80 of the processor emulator 60 are con- 
ventional components of the processor emulator and 
add supplemental control to the prototype hardware 
system. The user interface software 88 and the control 
circuit 80 also permit greater debugging capability for 
the target program 22. This allows the target program 
22 to be loaded, started, stopped, examined and modi- 
fied. The emulator memory 78 contains an emulator 
control program independent of the target program 22 in 
the memory 66. However, the target program 22 can 
also be loaded into the emulator memory 78 in what is 
sometimes called a memory overlay. Thus, the target 
program 22 can be executed from the memory 66, the 
emulator memory 78, or both. Execution of the target 
program 22 only from the emulator memory 78 allows 
execution of the target program without the benefit of 
software interaction with the target circuitry. 

A developer can use the processor emulator 60 to 
replace read-only memory (ROM), which will typically 
contain the target program in the final production model 
of the system, with a random access memory (RAM) 
overlay using the emulator memory 78. The RAM over- 
lay allows the developer to debug the target program 22 
even though the target hardware may not be completely 
available. The typical processor emulator 60 also pro- 
vides memory mapping software that detects when and 
where memory cycles occur. This allows the user to sin- 
gle-step through the execution of the target program. 
The processor emulator 60 also permits interruption of 
the target program 22 at specified instructions or when 
certain predefined conditions are met. Such predefined 
conditions include addresses references, interrupts, I/O 
instructions, and the like. The processor emulator facili- 
tates analysis of time-dependent problems in the target 
system by providing instruction execution trace fea- 
tures, complex breakpoint systems, and memory over- 
lays. 

Another form of hardware emulator, shown in Fig- 
ure 5, is a hardware circuit emulator 94. The hardware 
circuit emulator 94 uses reconfigurable circuitry 96, 
such as a field-programmable gate array (FPGA), to 
emulate target ciroiitry functions including the ASIC or 
custom IC. Companies such as Quickturn and Aptix 
have developed hardware circuit emulators which allow 
hardware designs to be downloaded into the reconfig- 
urable circuitry 96 and mounted on a board-like device. 
The hardware circuit emulator 94 includes a processor 
chip 100 and a memory 102 containing the target pro- 
gram 22. The hardware drcuit emulator 94 allows the 
target system to be tested as if it is already built. 

The hardware circuit emulator 94 is typically con- 
trolled from a computer workstation 104 or computer 



IS 



20 



25 



30 



6 



11 



EP0777180 A2 



12 



terminal, which contains a control program 106. The 
workstation is coupled to the hardware circuit emulator 
94 by a data link 61 . such as a serial, connection, paral- 
lel connection, network connection, or the like. The 
hardware circuit emulator 94 has the advantages of 5 
speed and early breadboard fabrication. However, high 
cost and tedium in configuration and debugging limit 
their application. These tools also lack hardware-soft- 
ware debugging visibility because access to internal 
registers and memory locations is not available. 10 

Hardware emulators, such as the processor emula- 
tor of Figure 4 or the hardware circuit emulator 94 of 
Figure 5. used to simulate circuit functions typically rep- 
resent a major investment on the user's part, in both 
design effort and capital cost. The benefit of using the is 
hardware emulator is in speed of detailed hardware 
simulation, which approaches the speed of the target 
system. While the hardware timing is not precise, it is a 
close approximation. System debugging remains a sig- 
nificant problem with hardware emulators because 20 
there is often little consideration of the software engi- 
neer. In order to load the design on the hardware emu- 
lator, one typically needs to represent the design in a 
detailed, structural form, which implies that the target 
hardware design has progressed very far along in the 25 
design process. This approach is often a costly develop- 
ment handicap because the development of the target 
program must await the completion of the target hard- 
ware. Thus, use of unsynthesizable behavioral or high- 
level design representations, typical of early stages of 30 
design, are precluded by the use of hardware emula- 
tors. By the time that target circuitry prototype is ready 
for use with hardware emulators, the product develop- 
ment is necessarily very far along in time, often practi- 
cally precluding the possibility of redesigning an ASIC 35 
that is already in place. Waiting for the target circuitry 
prototype also serializes the target program develop- 
ment process because the software development must 
await the development of the target circuitry prototype. 
This serialization of the target program causes 40 
unwanted delays in software debugging and system 
integration. 

The present invention allows for the early simula- 
tion of the target hardware and permits the parallel 
development of the target hardware and the target pro- 45 
gram. The system of the present invention also allows 
the extensive use of existing debugging tools to aid the 
developer in the development and integration of the tar- 
get system. The system combines interacting elements 
of hardware and executing software, in part by physical so 
emulation and in part by abstract software simulation. 

The present invention is embodied in a system 200 
shown in Figure 6. The system 200 includes a proces- 
sor emulator 202, such as the microprocessor emulator 
60 (see Figure 4) manufactured by Applied Microsys- ss 
tems Corporation and others. The processor emulator 
202 typically include the target microprocessor itself as 
the microprocessor 76. However, the microprocessor 76 
may be different from the target microprocessor and use 



additional components such as the FPGA to form a 
hardware circuit emulation of the target microprocessor. 
The operation of the processor emulator 202 is similar 
to that the of the conventional hardware emulators illus- 
trated in Figure 4 except for the operation of the control 
circuit 80 (see Figure 4) and the control program 104 
(see Figure 5). which are replaced by the function of the 
control circuit 204. The operation of the control circuit 
204 in the system 200 will be discussed in detail below. 

In the system 200. part of the target hardware is 
modeled by the processor emulator 202 and part of the 
target hardware Is modeled by a hardware simulator 
206. The hardware simulator 206 contains a processor 
model shell 210, which emulates the actual pin connec- 
tions for the target microprocessor. The hardware simu- 
lator 206 simulates the interaction between the target 
microprocessor and the target circuitry To model this 
interaction, the hardware simulator 206 must simulate 
the electrical and logical activity of the target circuitry at 
the pins of the target microprocessor. The processor 
model shell 210 is not the equivalent of the full func- 
tional processor 25 (see Rgure 1). but only models the 
activity of the target circuitry at the target microproces- 
sor pins. It should be noted that the conventional proc- 
essor emulator 60 (see Figure 4) includes the data bus 
72 which is physically plugged into the socket 70. How- 
ever, the processor emulator 202 of the present inven- 
tion does not utilize the data bus 72. but rather 
communicates with the hardware simulator 206 using 
computer functions, as will be described below. 

The processor emulator 202 typically has a first 
data format that is different from a second data format 
used by the hardware simulator 206. A software kernel 
212 is coupled between the processor ennulator 202 
and the hardware simulator 206 to convert from the first 
data format to the second data format. The software 
kernel 212 includes a translator 214 and a mapper 216. 
The translator 214 determines the nature of the 
required interaction and converts the interaction event 
from the first data format to an intermediate data format 
while the mapper 216 converts the intermediate data 
format into the second data format and generates a 
sequence of events for use at the hardware simulator 
206. The operation of the software kernel 212 and its 
components will be described in detail below. Thus, the 
translator 214 is specific to the processor emulator 202 
while the mapper 21 6 Is specific to the hardware simu- 
lator 206. The intermediate data format is a universal 
protocol that ensures compatibility between all transla- 
tors 214 and all mappers 21 6. 

The various components of the system 200 may be 
physically located in proximity with each other, and may 
even be portions of the same computer system. For 
example, the hardware simulator 206 and the software 
kernel 212 are both software components. These ele- 
ments of the system may be implemented in a single 
host computer. For the sake of clarity, the host computer 
is not illustrated herein. However, the hardware simula- 
tor 206 and the software kernel 212 may also be imple- 
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mented by different computer systems. The hardware 
simulator 206 and the software kernel 212 are coupled 
together by a communications link 220. which may be a 
programmatic interface if the hardware simulator and 
the software kernel are implemented in the same host 
computer. If the hardware simulator 206 and the soft- 
ware kernel 212 are implemented on separate compu- 
ter systems, the communications link 220 can be. for 
example, a serial connection, a parallel connection or a 
network connection. 

Similarly, the processor emulator 202 is coupled to 
the software kernel 212 by a communications link 222. 
As described above with respect to the communications 
link 220. the communications link 222 can be, for exam- 
ple, a serial connection, a parallel connection or a net- 
work connection. In the presently preferred 
embodiment, the communications link 222 from the 
processor emulator 202 to the software kernel 212. and 
the communications link 220 from the software kernel to 
the processor model shell 210 is implemented as a set 
of TCPIP sockets over an ethernet link. However, as 
those of ordinary skill in the art can readily appreciate, 
the communications links 220 and 222 may be imple- 
mented with other communications means such as 
serial and parallel communications ports, fiber optic 
FDDI links, and others as available. The present inven- 
tion is not limited by the particular form of the communi- 
cations links 220 and 222. 

The system 200 takes advantage of the combina- 
tion of modeling of the target microprocessor and the 
target program in the processor emulator 202 and of the 
target circuitry in the hardware simulator 206. The sys- 
tem 200 is significantly different from the hardware emu- 
lators, such as illustrated in Figures 4 and 5 because 
the system 200 simulates the target circuitry using the 
hardware simulator 206. This allows the software devel- 
oper to develop the target program before the target cir- 
cuitry is developed, unlike the prior art hardware 
emulators that require the development of the target cir- 
cuitry. 

The system further takes advantage of analysis that 
indicates that most of the computer instructions exe- 
cuted by the target program do not require interaction 
with the target circuitry. While the degree of interaction 
depends entirely on the specific application for which 
the target system is designed, studies indicate that the 
typical target program interacts with the target circuitry 
less than 20% of the time, with the remaining 80% of the 
time involving interaction between the target program 
and the target microprocessor. The system 200 uses 
the processor emulator 202. which is a high speed hard- 
ware device, to emulate the target microprocessor and 
the hardware simulator 206. which is a relatively stow 
software simulator, to model the target circuitry. Thus, 
the vast majority of the target program (typically 80% or 
more) is processed by the high-speed hardware por- 
tions of the system 200 while the smaller portions (typi- 
cally less than 20%) that requires interaction with the 
target circuitry is processed by the slower software por- 



tions of the system. This provides the advantage of 
high-speed operation of the target program for the por- 
tions of the system, such as the target microprocessor, 
that can be selected early in the design process. The 

5 system provides the further advantage of early simula- 
tion of the target hardware using the software modeling 
capability of the hardware simulator 206. Although the 
hardware simulator 206 is significantly slower than the 
processor emulator 202, the system 200 does not suffer 

10 from the slow instruction execution speed of prior art 
systems because most instruction are processed by the 
high-speed processor emulator with no hardware simu- 
lator interaction. Also, the complexity of most hardware 
modeled with a hardware simulator is much less com- 

15 plex than the hardware in the microprocessor. 

The software kernel 212 functions as a communica- 
tions controller when the target program 22 calls for 
interaction between the target microprocessor and the 
target circuitry. The translator 214 determines the type 

20 of interaction required by the processor emulator 202 
and hardware simulator 206 and translates the calls for 
such interaction from the first data format to the interme- 
diate data format for data going from the processor 
emulator 202 to the hardware simulator 206, and the 

25 mapper 216 converts the data in the intermediate for- 
mat into the second data format at the hardware simula- 
tor 206 and generates a sequence of functions that 
correspond to the event steps that are required for the 
hardware simulator to model the event. However, it 

30 should be understood that not all calls for interaction 
between the target microprocessor and the target cir- 
cuitry are initiated by the target microprocessor. For 
example, the target circuitry may generate an interrupt 
to the target microprocessor, which necessitates the 

35 transfer of data from the hardware simulator 206 to the 
processor emulator 202, The mapper 216 and translator 
214 operate in both directions to permit complete inter- 
action between the processor emulator 202 and the 
hardware simulator 206. For data going from the proc- 

40 essor emulator 202 to the hardware simulator 206, the 
translator 214 determines the nature of the event and 
translates from the first data format to the intermediate 
data format and the mapper 216 maps the data in the 
intermediate data format to the second data format and 

45 generates the appropriate sequence of functions at the 
hardware simulator 206. For data going from the hard- 
ware simulator 206 to the processor emulator 202, the 
mapper 216 maps the sequence of functions from the 
hardware simulator 206 in the second data format into 

50 data in the intermediate data format and the translator 
214 translates from the intermediate data format to the 
first data format to determine the nature of the required 
interaction. Thus, the software kernel 212 controls bidi- 
rectional communications and translation between the 

55 processor emulator 202 and the hardware simulator 
206. 

Operational details of the components of the sys- 
tem 200 will now be described. The hardware simulator 
206 is used to provide the external hardware response 
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to the target program 22 executing out of a memory 226 
associated with the processor emulator 202. While Fig- 
ure 6 illustrates the memory 226 as part of the proces- 
sor emulator 202. the system 200 is not limited to such 
a memory an-angement. For example the memory 226 5 
containing the target program 22 may exist as part of 
the processor emulator 202 or may be connected to the 
data bus 72 (see Figure 4) in the processor emulator or 
may be coupled to the processor emulator by other 
electrical means. 

Existing circuit descriptions, including HDL, are 
used to describe other target circuitry in the target hard- 
ware design. The processor model shell 210, using tiie 
HDL of the target circuitry, provides the communications 
and synchronization between the hardware simulator is 
206 and the software kernel 212. This communications 
and synchronization is provided in the same manner as 
the hardware simulator 20 (see Figure 1) of the prior art 
and need not be described in greater detail herein. 

Examples of the processor operating functions, 20 
illustrated in Figure 7, are defined to facilitate interaction 
between the processor emulator 202 and the processor 
model shell 210 in the hardware simulator 206. These 
processor operating functions include read and write 
functions for memory and input/output (I/O) operations. 25 
When an operation code (opcode) is executed in the tar- 
get program 22, the processor emulator 202. in cooper- 
ation with control circuitry 204. and software contained 
in the processor emulator recognizes if irrteraction 
between the target microprocessor and the target cir- 30 
cuitry needs to occur. If no external interaction is 
required, the target program 22 continues to execute 
unimpeded within the processor emulator 202. If inter- 
action Is required between the processor emulator 202 
and the hardware simulator 206, the translator 214. 35 
which is a software component, interprets the operation 
in process and communicates with the mapper 216. to 
convert the intended opcode operation to defined proc- 
essor functions. The processor model shell 210 per- 
forms the equivalent operation in the hardware 4o 
simulator 206 to convert the processor function to the 
simulated activity at the pins of the target microproces- 
sor. For example, if the event requiring interaction 
between the processor emulator 202 and the hardware 
simulator 206 is a 32-bit I/O write instruction (function 45 
16 in Figure 7), the processor emulator generates an 
I/O trap and the translator 214 fields the trap and deter- 
mines the type of trap. The translator 214 further con- 
verts the particular Instruction, the 32-bit I/O write in the 
present example) into the universal intermediate format, so 
The mapper 216 receives the intermediate format and 
converts the Instruction into a sequence of functions 
that are in the second format useable by the hardware 
simulator 206. In the present example, the address and 
data lines on the processor model shell 210 are ss 
changed at the appropriate times to simulate the 32-blt 
I/O write in the hardware simulator 206. In addition, 
other lines such as the Read/Write control line must be 
asserted and deasserted at the appropriate times in the 



simulation cycles of the hardware simulator. The map- 
per 216 will generate the various functions that corr - 
spond to events that occur in the target processor, but 
the functions are in the second data format used by the 
hardware simulator 206. Those of ordinary skill in the 
art can appreciate that different instruction types will 
result in a different sequence or sequences of function 
calls by the mapper 216. 

While the translator 214 determines the nature of 
the required interaction between the processor emula- 
tor 202 and the hardware simulator 206 and translates 
data between the first data format and the universal 
intermediate format, such translation is not required. In 
a preferred embodiment, the mapper 216 determines 
the nature of the required interaction requested by the 
target program 22 and directly generates the 
sequences of functions for the hardware simulator 206. 
For interaction requested by the hardware simulator 
206. the mapper 216 performs the reverse process with- 
out the need for the translator 214. When a read func- 
tion is executed, the data that the processor model shell 
210 reads from the hardware simulator 206 is reported 
back to the target program 22 by reversing the process. 

The processor emulator 202 contains both control 
circuitry 204 and a control program, both residing in the 
memory 226. which can identify conditions of the ex - 
cuting target program 22 and the surrounding hardware 
environment which will require communication with the 
hardware simulator 210. These conditions include 
explicit memory references outside of the loaded target 
program address range, input/output (I/O) operations, 
interrupt handling, and instructions dealing with explicit 
hardware functions, such as RESET. Those skilled in 
the art will recognize that other instruction may also 
require such interaction with the hardware simulator 
206 The control circuitry 204 in the processor emulator 
202 provides hardware capability to detect events 
requiring the interaction of the target microprocessor 
and the target circuitry. Similarly, the control program 
residing in the memory 226 provides software capability 
to detect events requiring the interaction of the target 
microprocessor and the target circuitry 

Because most of the target program 22 is executing 
unimpeded out of the memory 226 on the processor 76 
in the processor emulator 202, there Is no requirement 
for the processor model shell 210 to execute bus cycles 
such as instruction fetches in the hardware simulator 
206. Thus, the hardware simulator 206 is not synchro- 
nized to the processor emulator 202 except when there 
is an event requiring interaction between the target 
microprocessor and the target circuitry This means that 
when looking at data from the hardware simulator 206 
such as signal waveforms, the timing cycles in the proc- 
essor model shell 210 are precisely timing accurate 
because there is synchronization during events requir- 
ing interaction between the target microprocessor and 
the target circuitry. Furthermore, the execution time 
between cycles of the target program 22 will be fast 
when there is no event requiring interaction between the 
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target microprocessor and the target circuitry. However, 
the sequence of executed cycles is correct at all times, 
and the tasks performed by the target program 22 are 
functionally correct. Further, no modification of the tar- 
get program 22 by the user is needed, at the source 5 
level or object code level to operate with the system 
200. 

Another significant advantage of the system 200 is 
that conventional development tools that run on the tar- 
get processor can be used with the target program 22. 10 
For example, conventional software debuggers, operat- 
ing systems, and the like can be used with the target 
program 22 in a normal fashion. Thus, the system 
developer can utilize afl the conventional development 
tools to assist in the development of the target program, is 
This is unlike prior art systems, such as the hardware 
simulator 20 (see Figure 1) where the system developer 
cannot use debugging tools. 

This system 200 is capable of handling hardware 
interrupts to the target program 22. Interrupts received 20 
by the processor model shell 210 within the hardware 
simulator 206 are communicated to the software kernel 
212 and translated as an interrupt to the target program 
22. Within the target program 22, the programmer can 
create an interrupt handler, which is invoked asynchro- 25 
nously on receipt of an inten-upt. Facilities exist for inter- 
rupt masking, fully supporting the hardware equivalent 
found in the target system. These facilities ensure that 
the system 200 is compatible with interrupt driven code. 

The operation of the system 200 is illustrated in the 30 
flowcharts of Figures 8A and 8B. Figure 8A illustrates 
the operation of the system 200 when the interaction 
between the target microprocessor and the target cir- 
cuitry is initiated by the target microprocessor. At the 
start 300 the target program 22 is executing on the proc- 35 
essor emulator 202 (see Figure 6). The target program 
22 typically contains an I/O reference instruction 302, a 
processor specific operation 304, and an external pro- 
gram memory reference 306. It should be noted that it is 
not essential to the operation of the system 200 that the 40 
target program 22 contain all of the elements described 
above. When the target program 22 executes an I/O ref- 
erence instruction 302, the system 200 generates an 
I/O instruction trap in step 310. Similarly, if the target 
program 22 executes a processor specific operation 45 
304, the system generates a processor specific opera- 
tion trap in step 312. If the target program 22 executes 
an external program memory reference 306, the system 
generates an out of bounds memory reference trap in 
step 314. so 

In step 318, the system 200 isolates and identifies 
the cause of the trap generated in steps 310, 312, or 
314. In step 320, the system 200 calls the translation 
software in the translator 214 (see Figure 6). In step 
324, the translator 214 translates the trap to a function 55 
call sequence or sequences. In step 328, the software 
kernel 212 invokes a processor interface function. 

Certain processor interface functions, such as 
breakpoint, an instruction trace, or memory reference to 



a location inside the emulator 202 (see Figure 6). 
require no response from the target circuitry. In this 
case, the system 200 moves to step 334 and resumes 
normal program execution of the target program 22, 
Other processor interface functions, such as an I/O 
Read instruction, require a response from the target cir- 
cuitry In this event, the mapper 216 maps the processor 
interface function to the appropriate processor hard- 
ware pin timing and sequencing in step 330. Some 
interface functions, such as setting the inten-upt mask 
register, require no simulator cycles in the hardware 
simulator 206. The system 200 merely sets the Interrupt 
mask register in the processor model shell 210, which 
completes the task without requiring the hardware sim- 
ulator to execute any simulator cycles. In this event, the 
system jumps to step 334 and resumes normal program 
execution. Other processor interface functions, such as 
an I/O Read or I/O Write, require one or more cycles in 
the hardware simulator 206. In this case, the system, in 
step 332. completes the hardware simulation cycles 
required by the specific interface function using the 
hardware simulator 206 in the manner described above. 
When the hardware simulator 206 has completed the 
required cycles, the system 200 moves to step 334, and 
resumes normal execution of the target program 22. 
Thus, the system 200 responds to various instructions 
in the target program 22 that require interaction with the 
target circuitry simulated in the hardware simulator 206. 

As previously discussed, the target circuitry may 
also initiate an event requiring interaction between the 
target microprocessor and the target circuitry. This is 
illustrated in Rgure 8B, where at the start 350, the tar- 
get program 22 (see Figure 6) is executing on the proc- 
essor emulator 202. In step 352, the target circuitry, 
simulated on the hardware simulator 206 (see Figure 6), 
signals an inten-upt or other condition, such as Power 
On. RESET. Bus Error, Address Error. Memory Fault. 
Non-Maskable Interrupt, and the like, requires interac- 
tion between the target circuitry and the target micro- 
processor. In step 354. the simulator interface, using the 
processor model shell 210, initiates a bus action corre- 
sponding to the particular interrupt or condition. This 
includes the generation of both timing and signal 
sequencing to simulate the activity of the target circuitry 
In step 356. the processor model shell 210 communi- 
cates with the mapper 216. In step 360. the mapper 216 
connects the hardware interrupt to a processor interface 
function. In step 362, the translator 214 translates the 
interface function to a call sequence or sequences. In 
step 364. the system invokes an emulator communica- 
tions call. 

In step 368, the system 200 transfers the call 
sequence to the emulator interrupt control. In step 370, 
the processor emulator 202 (see Figure 6) simulates a 
machine interrupt condition. In step 372. the processor 
enrujiator 202 inten-upts the normal flow of the target 
program 22 and transfers control to an interrupt handler 
in the target program. In step 374, the target program 22 
processes the target interrupt using the target interrupt 
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handler. Upon completion of the target interrupt 
processing, the system 200 returns control to the target 
program 22, which continues normal program process- 
ing. Thus, as Illustrated in Figures 8A and 8B, the sys- 
tem 200 processes requests for interaction between the 5 
target microprocessor and the target circuitry regard- 
less of which portion of the target system initiated the 
event requiring such interaction. 

The system 200 also supports split execution 
across a network, computer workstation to computer 10 
workstation. This is especially important for design 
groups where the hardware designers work with tools 
that run on one platform type, and the software design- 
ers work with tools that run on different platform type. 
With the system 200. the hardware simulator 206 can is 
execute on the hardware designer's workstation, and 
the software kernel 212 can execute on the software 
engineers' machines. The target program 22. along with 
debuggers and other software development tools, exe- 
cute on the processor emulator 202, which is a network 20 
sharable resource. In this manner, it is possible to run 
the software and hardware debuggers simultaneously, 
allowing both hardware and software analysis at will. 
Thus, the system 200 Is not limited to execution of a sin- 
gle platform, but permits simultaneous development by 25 
a number of different development groups In different 
physical locations sharing resources on communica- 
tions links such as a network. 

In another embodiment of the system 200, multiple 
processor emulators 202 can support simultaneous tar- 30 
get programs executing concurrently, as illustrated in 
Figure 9. Each processor emulator 202 maintains syn- 
chronization locally and executes its own target pro- 
gram 22 (see Figure 6). If one processor emulator 202 
Is waiting for something to happen, this does not pre- 35 
vent another processor emulator from executing Inde- 
pendently The functions performed by the software 
kernel 212 and the processor model shell 210 in the 
hardware simulator 206 are identical to that previously 
described with respect to the system of Figure 6 except 40 
that the software kernel is coupled to two processor 
emulators 202. A communications link 390 couples the 
software kernel 212 to the additional processor emula- 
tor 202. While the system illustrated in Figure 9 includes 
only two processor emulators 202. there are no restric- 45 
tions on the number of processor emulators that can be 
included within the system 200. It should be noted that 
the processor emulators 202 may use different target 
microprocessors. 

In another embodiment. Illustrated in Figure 10, the so 
system 200 uses a processor and memory simulation 
engine 392 in place of the second processor emulator 
202 described in Figure 9. The processor and memory 
simulation engine 392 may, for example, be the ISS 40 
(see Figure 2). The processor and memory simulation ss 
engine 392 communicates with the software kernel 212 
in the manner described above with respect to Rgures 
6 and 9. While the processor and memory simulation 
engine 392 may not provide the detailed Internal timing 



and debugging capabilities of the processor emulator 
202. it can provide the functionality of the target micro- 
processor. 

It is to be understood that even though various 
embodiments and advantages of the present invention 
have been set forth in the foregoing description, the 
above disclosure is illustrative only, and changes may 
be made in detail, yet remain within the broad principles 
of the invention. Therefore, the present invention is to be 
limited only by the appended claims. 

Claims 

1. A system for testing and analyzing electronic sys- 
tems, including a target microprocessor and simu- 
lated target circuitry, and accompanying target 
program to be executed on the target microproces- 
sor, the system comprising: 

a memory storing a plurality of computer 
instructions, said computer instructions includ- 
ing the target program; 

a processor emulator employing a hardware 
device for emulating the target microprocessor, 
said processor emulator coupled to said mem- 
ory to execute said computer instructions: 
a hardware simulator coupled to said proces- 
sor emulator to simulate the target circuitry; 
and 

a communications interface to control commu- 
nication between said processor emulator and 
said hardware simulator, said processor emu- 
lator communicating with said memory to 
receive said computer instructions from said 
memory, and said processor emulator commu- 
nicating with said hardware simulator using 
said communications interface only when an 
event requires Interaction of the target program 
with the target circuitry. 

2. The system of claim 1 wherein said processor emu- 
lator is coupled to said hardware simulator by a 
computer network connection, said communica- 
tions interface controlling communications over 
said network. 

3. The system of claim 1, further Including an excep- 
tion detector coupled to said processor emulator to 
detect said event requiring the target program to 
interact with the target circuitry. 

4. The system of claim 3 wherein said exception 
detector temporarily halts execution of said plurality 
of computer instructions while said hardware simu- 
lator processes said event requiring the target pro- 
gram to interact with the target circuitry. 

5. The system of claim 1 wherein said event requiring 
the target program to interact with the target cir- 
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cuitry is an input/output (I/O) instruction to said 
hardware simulator, and said communication inter- 
face controls communication of said I/O instruction 
from said processor emulator to said hardware sim- 
ulator. 5 

6. The system of claim 1 wherein said processor emu- 
lator uses a first data format and said hardware 
simulator uses a second data format, the system 
further including a translator to convert said event io 
requiring the target program to interact with the tar- 
get circuitry from said first data format to one or 
more function calls in said second data format. 

7. The system of claim 6 wherein said hardware simu- is 
lator contains a processor model shell to simulate 
activity of the pins of the target microprocessor, the 
system further including a mapper to map said 
function calls from said second data format to a set 

of signal sequences compatible with the processor 20 
model shell. 

8. The system of claim 7, further including a computer 
communicating with said processor emulator, said 
computer also executing said hardware simulator, 25 
said translator, and said mapper. 

9. The system of claim 7 wherein said processor emu- 
lator is coupled to said translator and said mapper 

by a first computer network connection, said com- 30 
munications interface controlling communication 
over said first network connection. 

10. The system of claim 9, wherein said translator and 
said mapper are coupled to said hardware Simula- 35 
tor by a second computer network connect" on, said 
communications interface controlling communica- 
tion between said processor emulator and said 
hardware simulator over said first and second net- 
work connections. 40 

11. The system of claim 1 wherein said processor emu- 
lator is a microprocessor emulator with said mem- 
ory integrated therein, said integrated memory 
containing said computer instructions. 45 

. 1 2. The system of claim 1 wherein said processor emu- 
lator is a hardware circuit emulator with said mem- 
ory integrated therein, said integrated memory 
containing said computer instructions. so 

13. The system of claim 1 , further including a computer 
communicating with said processor emulator, said 
computer also executing said hardware simulator. 

55 

14. The system of claim 1 wherein said hardware simu- 
lator contains a processor model shell to simulate 
activity of the pins of the target microprocessor, the 
system further including a mapper to map said 



event requiring the target program to interact with 
the target circuitry to a set of signal sequences 
compatible with the processor model shell. 

15. The system of claim 14, further including a compu- 
ter communicating with said processor emulator, 
said computer also executing said hardware simu- 
lator and said mapper. 

16. A system for testing and analyzing electronic sys- 
tems, including first and second target microproc- 
essors and simulated target circuitry, and 
accompanying target program to be executed on 
each of the target microprocessors, the system 
comprising: 

a first memory storing a first set of computer 
instructions for the first target microprocessor, 
said first set of computer instructions including 
the target program for the first target microproc- 
essor; 

a first processor emulator employing a hard- 
ware device for emulating the first target micro- 
processor, said first processor emulator 
coupled to said first memory to execute said 
first set of computer instructions; 
a second memory storing a second set of com- 
puter instructions for the second target micro- 
processor, said second set of computer 
instructions including the target program for the 
second target microprocessor; 
a second processor emulator employing a 
hardware device for emulating the second tar- 
get microprocessor, said second processor 
emulator coupled to sard second memory to 
execute said second set of computer instruc- 
tions; 

a hardware simulator coupled to said first and 
second processor emulators to simulate the 
target circuitry; and 

a communications interface to control commu- 
nication between said first and second proces- 
sor emulators and said hardware simulator, 
said first and second processor emulators 
communicating with said first and second 
memories, respectively to receive said first and 
second sets of computer instructions from said 
first and second memories, said first processor 
emulator communicating with said hardware 
simulator using said communications interface 
only when an event requires interaction of the 
target program for the first target microproces- 
sor with the target circuitry, and said second 
processor emulator communicating with said 
hardware simulator using said communications 
interface only when an event requires interac- 
tion of the target program for the second target 
microprocessor with the target circuitry. 
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17. The system of claim 16 wherein said communica- 
tions controller has first and second portions, said 
first communications controller portion being opera- 
tively coupled to said first processor emulator to 
control communications between said first proces- s 
sor emulator and said hardware simulator only on 
said event when the target program for the first tar- 
get microprocessor requires interaction with the tar- 
get circuitry, said second communications 
controller portion being operatively coupled to said io 
second processor emulator to control communica- 
tions between said second processor emulator and 
said hardware simulator only on said event when 
the target program for the second target microproc- 
essor requires Interaction with the target circuitry 75 

18. The system of claim 16 wherein said first and sec- 
ond processor emulators are each coupled to said 
hardware simulator by a computer network connec- 
tion, said communications interface controlling 20 
communications over said network connections. 

19. The system of claim 16, further including first and 
second exception detectors coupled to said first 
and second processor emulators, respectively, said 25 
first exception detector detecting said event when 
the target program for the first target microproces- 
sor requires interaction with the target circuitry, and 
said second exception detector detecting said 
event when the target program for the second target 30 
microprocessor requires interaction with the target 
circuitry. 

20. The system of claim 19 wherein said first exception 
detector temporarily halts execution of said first set 35 
of computer instructions while said hardware simu- 
lator processes said event when the target program 

for the first target microprocessor requires interac- 
tion with the target circuitry, and said second excep- 
tion detector temporarily halts execution of said 40 
second set of computer instructions while said 
hardware simulator processes said event when the 
target program for the second target microproces- 
sor requires interaction with the target circuitry 

45 

21. The system of claim 16 wherein said event when 
the target program for the first target microproces- 
sor requires interaction with the target circuitry is an 
input/output (I/O) instruction to said hardware simu- 
lator, and said communication interface controls so 
communication of said I/O instruction from said first 
processor emulator to said hardware simulator. 

22. The system of claim 16 wherein said event when 
the target program for the second target microproc- 55 
essor requires interaction with the target circuitry is 

an input/output (I/O) instruction to said hardware 
simulator, and said communication interface con- 
trols communication of said I/O instruction from 



said second processor emulator to said hardware 
simulator. 

23. The system of claim 16 wherein said first and sec- 
ond processor emulators use a first data format and 
said hardware simulator uses a second data for- 
mat, the system further including a translator to 
convert said events when the target program for the 
first and second target microprocessors require 
interaction wrth the target circuitry from said first 
data format to one or more function calls in said 
second data format. 

24. The system of claim 23 wherein said hardware sim- 
ulator contains first and second processor model 
shells to simulate activation of the pins of the first 
and second target microprocessors, respectvely, 
the system further including a mapper to map said 
function calls for the first target microprocessor 
from said second data format to a set of signal lines 
compatible with said first processor model shell, 
and to map said function calls for the second target 
microprocessor from said second data format to a 
set of signal sequences compatible with said sec- 
ond processor model shell. 

25. The system of claim 24, further including a compu- 
ter communicating with said first and second proc- 
essor emulators, said computer also executing said 
hardware simulator, said translator, and said map- 
per. 

26. The system of claim 23 wherein said first and sec- 
ond processor emulators are coupled to said trans- 
lator by a first computer network connection, said 
communications interface controlling communica- 
tion over said first network connection. 

27. The system of claim 26 wherein said translator is 
coupled to said hardware simulator by a second 
computer network connection, said communica- 
tions interface controlling communication between 
said processor emulator and said hardware simula- 
tor over said first and second network connections. 

28. The system of claim 16 wherein said first and sec- 
ond processor emulators are microprocessor emu- 
lators with said first and second memories, 
respectively, integrated therein, said first integrated 
memory storing said first set of computer instruc- 
tions for the first target microprocessor, and said 
second integrated memory storing said second set 
of computer instructions for the second targ t 
microprocessor. 

29. The system of claim 16 wherein said first and sec- 
ond processor emulators are hardware circuit emu- 
lators with said first and second memories, 
respectively integrated therein, said first integrated 
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memory storing said first set of computer Instruc- 
tions for the first target microprocessor, and said 
second integrated memory storing said second set 
of computer instructions for the second target 
microprocessor. 5 

30. The system of claim 16. further including a compu- 
ter communicating with said first and second proc- 
essor emulators, said computer also executing said 
hardware simulator. io 

31 . The system of claim 1 6 wherein said hardware sim- 
ulator contains first and second processor model 
shells to simulate activity of the pins of the first and 
second target microprocessors, respectively, the 75 
system further including a mapper to map said 
event requiring the target program for the first target 
microprocessor to interact with the target circuitry 

to a set of signal sequences compatible with the 
first processor model shell, said mapper also map- 20 
ping said event requiring the target program for the 
second target microprocessor to interact with the 
target circuitry to a set of signal sequences compat- 
ible with the second processor model shell. 

25 

32. The system of claim 31 . further including a compu- 
ter communicating with said processor emulator, 
said computer also executing said hardware simu- 
lator and said mapper. 

30 

33. A system for testing and analyzing a electronic sys- 
tems, including a target microprocessor and a tar- 
get program to be executed on the target 
microprocessor, and simulated target circuitry sim- 
ulated on a hardware simulator, the system com- 35 
prising: 

a processor emulator employing a hardware 
device for emulating the target microprocessor, 
said processor emulator including a memory 40 
for storing and executing the target program; 
a processor model shell substituting for a proc- 
essor model in the hardware simulator; said 
processor model shell simulating activity of the 
pins of the target microprocessor; 45 
interaction detection means coupled to the 
processor emulator and said processor model 
shell, said interaction detection means recog- 
nizing, in cooperation with said processor emu- 
lator, when the target program needs to interact so 
with the target circuitry in the hardware simula- 
tor; and 

a communication link coupling said processor 
model shell to said interaction detection means 
and coupling said interaction detection means 55 
to said processor emulator, whereby the sys- 
tem simulates the functional behavior of the 
target microprocessor executing target pro- 
grams acting in conjunction with simulated tar- 



get circuitry. 

34. The system of claim 33 wherein said interaction 
detection means includes a software kernel com- 
municating with the processor emulator and said 
processor model shell to detect when the target 
program needs to interact with the target circuitry in 
the hardware simulator. 

35. The system of claim 34 wherein said software ker- 
nel translates operational requests from the target 
program requiring interaction with the target cir- 
cuitry in the hardware sinrtulator and maps said 
operational requests into processor functions for 
communication to said processor model shell. 

36. The system of claim 34 wherein said software ker- 
nel maps hardware generated requests from said 
processor model shell requiring interaction with the 
target program, said software kernel translating and 
communicating said hardware generated requests 
to the target program in said processor emulator. 

37. The system of claims 34 for operation with external 
computers wherein said hardware simulator is exe- 
cuted by a first of the external computers and said 
software kernel is executed by a second of the 
external computers. 

38. The system of claim 34 wherein said software ker- 
nel comprises a plurality of logical functions, said 
logical functions being distributed as control pro- 
gram elements in said processor emulator control 
software, and as part of said processor model shell 
operating in conjunction with the hardware simula- 
tor. 

39. The system of claim 34, further including a compu- 
ter communicating with said processor emulator, 
said computer also executing the hardware simula- 
tor, including said processor model shell, and said 
software kernel. 

40. The system of claim 33 wherein said processor 
emulator includes hardware control circuitry and 
control software and said interaction detection 
means uses said control circuitry to selectively rec- 
ognize when the target program needs to interact 
with the target circuitry in the hardware simulator, 
said control circuitry interrupting execution of the 
target program when the target program needs to 
interact with the target circuitry in the hardware sim- 
ulator and otherwise allowing uninterrupted execu- 
tion of the target program. 

41. The system of claim 33 wherein said processor 
emulator includes control circuitry and control soft- 
ware and said interaction detection means uses 
said control software to selectively recognize when 
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the target program needs to interact witfi the target 
circuitry in the hardware simulator, said control soft- 
ware interrupting execution of the target program 
when the target program needs to Interact with the 
target circuitry in the hardware simulator and other- 5 
wise allowing uninterrupted execution of the target 
program. 

42. The system of claim 33 wherein the hardware sim- 
ulator and said processor model shell are executed 10 
on a computer workstation and said communication 
link controls communication between said emulator 
and said workstation. 

43. The system of claim 33 wherein said processor is 
emulator is a microprocessor emulator with mem- 
ory integrated therein, said integrated memory con- 
taining the target program, said microprocessor 
emulator communicating with said interaction 
detection means acting in conjunction with the sim- 20 
ulated target circuitry 

44. The system of claim 33 wherein said processor 
emulator is a hardware circuit emulator with mem- 
ory integrated therein, said integrated memory con- 25 
taining the target program, said hardware emulator 
communicating with said interaction detection 
means acting in conjunction with the simulated tar- 
get circuitry 

30 

45. The system of claim 33 wherein said communica- 
tion link supports TCPIP socket protocols. 

46. The system of claim 33 wherein said communica- 
tion link coupling said processor model shell to said 35 
software kernel and coupling said software kernel 

to said processor emulator are software program 
calls. 

47. The system of claim 33 wherein said processor 40 
emulator means is a microprocessor emulator with 
integrated memory contained therein, the system 
further including external memory coupled to said 
microprocessor emulator through a microprocessor 
bus connection with the target program contained 45 
in a program memory comprising at least one of 
said integrated and external memories. 

48. The system of claim 47 wherein the target program 

is contained in both said integrated and external so 
memories. 

49. The system of claim 33. further including an addi- 
tional processor emulator employing a hardware 
device for emulating an additional target microproc- ss 
essor, said additional processor emulator including 

an additional memory for storing and executing a 
target program to be executed on said additional 
target microprocessor wherein said software kernel 



recognizes, in cooperation with said additional 
processor emulator, when said target program to be 
executed on said additional target microprocessor 
needs to interact with the target circuitry in the 
hardware simulator. 

50. A system for testing and analyzing a computer sys- 
tem, including a processor emulator employing a 
hardware device for emulating a target microproc- 
essor, said processor emulator including a memory 
for storing and executing a target program to be 
executed on the target microprocessor, and simu- 
lated target circuitry simulated on a hardware simu- 
lator, the system comprising: 

a software kernel communicating with the proc- 
essor emulator and the hardware simulator, 
said software kernel recognizing, in coopera- 
tion with the processor emulator, when the tar- 
get program needs to interact with the target 
circuitry in the hardware simulator; and 
a communication link coupling the hardware 
simulator to said software kernel and coupling 
said software kernel to the processor emulator, 
whereby the system simulates the functional 
behavior of the target microprocessor execut- 
ing target programs acting in conjunction with 
simulated target circuitry. 

51. A method for testing and analyzing computer hard- 
ware, including a target microprocessor and simu- 
lated target circuitry, and accompanying software to 
be executed on the target microprocessor, the sys- 
tem comprising: 

storing a plurality of computer instructions in a 
memory, said computer instructions including 
the accompanying software; 
emulating the target microprocessor using a 
processor emulator hardware device, said 
processor emulator coupled to said memory to 
execute said computer instructions; 
simulating the target circuitry using a hardware 
simulator coupled to said processor emulator; 
and 

controlling communication between said proc- 
essor emulator and said hardware simulator, 
said processor emulator communicating with 
said memory to receive said computer instruc- 
tions from said memory, and said processor 
emulator communicating with said hardware 
simulator only when an event requires the tar- 
get microprocessor to interact with the target 
circuitry. 

52. The method of claim 51 , further including the step 
of detecting said event when the target microproc- 
essor needs to interact with the target circuitry 
using an exception detection software routine. 
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53. The method of claim 51 wherein said event when 
the target microprocessor needs to interact with the 
target circuitry is an input/output (I/O) instruction to 
said hardware simulator, and said set of controlling 
communication, controls communication of said I/O s 
instruction from said processor emulator to said 
hardware simulator. 

54. The method of daim 51 wherein said processor 
emulator uses a first data format and said hardware io 
simulator uses a second data format, the method 
further including the step of converting said event 
when the target microprocessor needs to interact 
with the target circuitry from said first data format to 
one or more functions in said second data format. 75 

55. The method of claim 54 wherein said hardware sim- 
ulator contains a processor model shell to simulate 
activity of the pins of the target microprocessor, the 
method further including the step of mapping said 20 
functions in said second data format to a set of sig- 
nal sequences conpatible with the processor 
model shell. 



simulating the target circuitry using said hardware 
simulator and said step of mapping. 

62. The method of claim 51 for use with an additional 
processor emulator employing a hardware device 
for emulating an additional target microprocessor, 
the additional processor emulator including an 
additional memory for storing and executing a tar- 
get program to be executed on the additional target 
microprocessor, the method further including the 
steps of controlling communication between the 
additional memory, the additional processor emula- 
tor and said hardware simulator, the additional 
processor emulator communicating with the addi- 
tional memory to receive computer instructions, 
including the target program to be executed on the 
additional target microprocessor, from the addi- 
tional memory, and the additional processor emula- 
tor communicating with said hardware simulator 
only on an event when the additional target micro- 
processor needs to interact with the target circuitry. 



56. The method of claim 55 for use with a computer 25 
communicating with said processor emulator, 
wherein said computer also performs said steps of 
simulating the target circuitry using said hardware 
simulator, converting said event, and mapping. 

30 

57, The method of claim 55 wherein said processor 
emulator is coupled to said translator and said map- 
per by a first computer network connection and said 
step of controlling communications controls com- 
munications over said first network connection. 35 



58. The method of claim 56 wherein said translator and 
said mapper are coupled to said hardware simula- 
tor by a second computer network and said step of 
controlling communications controls communica- 40 
tions over said second network connection. 

59. The method of claim 51 for use with a computer 
communicating with said processor emulator, 
wherein said computer also performs said step of 45 
simulating the target circuitry using said hardware 
simulator 



60. The method of claim 51 wherein said hardware sim- 
ulator contains a processor model shell to simulate so 
activity of the pins of the target microprocessor, the 
method further including the step of mapping said 
event requiring the target program to interact with 
the target circuitry to a set of signal sequences 
compatible with the processor model shell. 55 

61. The method of claim 60 for use with a computer 
communicating with said processor emulator, 
wherein said computer also performs said step of 
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